@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
  "optionalDependencies": {
    "fsevents": "*"
  }
}

Install with:
npm install --no-optional

is this expected to fix npm/npm#18712 ?

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

This is insane. Why does lowering the priority of some garbage logs, that are by definition irrelevant to the computer that you're running them on, take half a decade to resolve? Just for political reasons, even though the code fix was provided years ago?

This is legislation by inaction that makes the federal government look fast and responsive.

And people are yelling at the person who supplied the fix, for suggesting that maybe SEVERAL YEARS is too long to keep a trivial PR open (after having their previous PR declined by a bot).

No one wants to contribute to a project that can't merge a trivial PR after years of discussion and hundreds of users asking for it.

@Pointotech I dunno if it’s political. My guess is that the managers at NPM don’t realize that there are people who (formerly) would take time out of their day to improve their product for free simply because they want it to be better, and thus they never schedule time to work through open PRs. Gosh, you’d think: prioritizing reviewing already-written changes that users want ahead of other things like writing new changes from scratch.

It’s a real shame that in the last four years by inaction they have demonstrated that they still haven’t realized this. It’s especially bizarre considering they upload their software to a FOSS social network. And rather deceptive, I feel; by ostensibly “accepting PRs” to their repositories, they establish an expectation that this is a commune in which a fair exchange of value for the submission of a PR is a timely response of feedback/rejection/acceptance. Otherwise, contributors leave the commune, like I have.

Except, despite that I will not be writing code for NPM nor using their CLI, I’m still posting here because I care about Node, and the NPM CLI is knotted into Node. So if NPM being acquired by a trillion dollar company is still insufficient to get PRs merged, I guess our only hope is to change maintainership out from underneath them. But Node doesn’t seem to want to do that either, so I guess it will just suck.

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

I don't know why should I be warned even using normal working modules.

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...